User talk:Peter coxhead/Archive 13

This is an archive of past discussions about User:Peter coxhead. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 10

Archive 11

Archive 12

→

Excavata colours

Speaking of hardcoded colours...the taxoboxes that contain unranked_regnum = [[Excavata]] are all hardcoded with RGB(250,250,100), because automatic colour selection doesn't work with that clade. I'm afraid I inserted a lot of those codes myself, because it seemed better than retaining the spurious Kingdom Excavata. If you were to adapt Template:Taxobox colour to seek colours for unranked_regnum = [[Excavata]] I could pull out all those hardcoded yellows, if you like. Unfortunately, Excavata's monophyly is in doubt, so perhaps it makes sense to wait, before going to the trouble? Deuterostome (Talk) 19:16, 1 November 2016 (UTC)

@Deuterostome: I just removed the hard-coded colour at Euglenozoa, and it still works fine. Can you tell me where |unranked_regnum=[[Excavata]] doesn't work? Of course, it's possible that some of the changes I've been making over the last couple of days have fixed something that wasn't working before. The entire taxobox colour template code is a maintenance nightmare! Peter coxhead (talk) 19:32, 1 November 2016 (UTC)

You're right! I tried it on a half dozen pages, and it worked perfectly. I definitely tested it a couple of days ago, before making a few dozen edits; so, either I made a mistake when testing, or the template has mysteriously healed itself. :D I'll extract the Excavata codes, when I have time (probably tomorrow). I'll take care of the "greenyellow" infestation in SAR pages, too, but that'll take a bit longer. There are well over a thousand articles to review. Deuterostome (Talk) 20:54, 1 November 2016 (UTC)

Considering the time I've spent on it, I doubt that it "healed itself"! :-) Anyway, we seem to be making progress. Let me know if you find any taxoboxes that should generate the right colour, but don't. Peter coxhead (talk) 21:00, 1 November 2016 (UTC)

Huh, I thought those rattling, whistling, wheel-and-chain-driven templates sort of maintained themselves. :p I pulled out the Excavata colors, and nothing spooky happened. Excavata itself might be going out of business, but that's a problem for another day. Deuterostome (Talk) 12:10, 2 November 2016 (UTC)

Liriope (genus)

Could you please move Liriope (genus) to Liriope (plant)? There's also a genus Liriope (jellyfish), so (genus) isn't sufficient disambiguation.

Done Peter coxhead (talk) 08:53, 2 November 2016 (UTC)

There's a little complication with it being the exemplar at {{Speciesbox/doc}} of a taxonomy template that doesn't need to be disambiguated even though the parent article requires it. I'm not quite sure what should happen {{Taxonomy/Liriope}}; move and take the redirect RfD? Delete by moving without leaving a redirect (is that kosher?)?

I'd suggest Cancer (genus) as the new exemplar for the speciesbox documentation, if it's desirable to have an exemplar that uses "(genus)" as a dab term. Cancer (crab) is potentially ambiguous with astronomy/astrology topics, so I doubt that there's any chance the genus will ever take a different dab term. The only problem is, it's not using an autotaxobox. I'm not aware of any great candidate exemplars that do currently use an automatic taxobox (Asparagus (genus) is the best I can think of, but would require a little rewording of the speciesbox documention). Plantdrew (talk) 02:51, 2 November 2016 (UTC)

I took out the example at {{Speciesbox/doc}} for the present.

The question, I think, is whether both the taxonomy templates for the plant and jellyfish genera need disambiguation.

There's no problem with having an article at "X (plant)" and the taxonomy template at "Template:Taxonomy/X" if the need to differentiate X arises from non-genera, as was the case with Liriope.
There's no need to differentiate all uses of X in articles; if one is clearly the main use, it goes at "X", and the rest have disambiguation terms added to their titles.

So if one use of X as a genus name is clearly main, I don't see why the taxonomy templates shouldn't be at "Template:Taxonomy/X" for the main genus use and "Template:Taxonomy/X (y)" for the secondary genus use. It's certainly the case for Liriope that plant is well-known in gardens and the jellyfish genus has only one species, so as a genus name, "Liriope" has its main use for the plant. Hence I would keep Template:Taxonomy/Liriope for the plant, and use Template:Taxonomy/Liriope (jellyfish) for the other. Peter coxhead (talk) 09:27, 2 November 2016 (UTC)

OK, sounds reasonable about the template. Is that also your reasoning for leaving Lirope (genus) pointing to the plant and not the dab page? To me, that undermines the point of moving in the first place (especially when the other dab rcat template says that the redirect is not an incomplete disambiguation). Plantdrew (talk) 16:43, 2 November 2016 (UTC)

No, that was an mistake: it's become too automatic after an article/redirect swap to change the redirect to point to the article. Corrected now. Please check that the Rcat is correct. Peter coxhead (talk) 17:07, 2 November 2016 (UTC)

Cryptists & Archaeplastida

Curious to know your source (am I falling behind? ;)). Burki et al, 2016 drops them into the middle Archaeplastida, sister to green algae & land plants, with rhodophytes basal to both groups. Deuterostome (Talk) 10:34, 3 November 2016 (UTC)

Yes, I realize that my edit summaries weren't quite right, although I'm doubtful that we can take Burki et al. (2016) as definitive, given that other papers since 2014 reach different conclusions. But by all means put them elsewhere if you think it's justified. The real point as that they aren't "incertae sedis" and shouldn't be treated as such, since at the very least they are eukaryotes. Peter coxhead (talk) 10:42, 3 November 2016 (UTC)

@Deuterostome: to be clear, I'm taking a conservative view: unless the article clearly has another 'colour determining taxon' in the taxobox, I'm just treating it as a eukaryote. Other editors are free to assign more specific colours; hopefully later this will all be automated. Peter coxhead (talk) 11:00, 3 November 2016 (UTC)

I agree with that approach, and consider it wise not to shuffle taxa about every time a new phylogeny is proposed. I have no problem with restricting use of incertae sedis, and using Eukaryota as the colour. In coming years, we're going to see lots of new eukaryotes of uncertain affinity (a friend has a lab full of undescribed kingdom-level critters, just waiting to mess up Wiki's templates!), and we'll need somewhere to stick them until taxonomy can catch its breath. :D Deuterostome (Talk) 11:27, 3 November 2016 (UTC)

I guess the deeper question is "What are the taxobox colours for?" The answer has to involve readers, rather than editors. I strongly suspect that readers would have been better served by treating all single-celled eukaryotes ("protists") as a grade with a single taxobox colour (at most separating out green algae); only experts are going to be interested in the subgroups of this grade, and they don't need colours anyway, since they will recognize the names (well, they will if they read every latest paper!). However, we are where we are, and I think that the approach I've taken works adequately and seems to be supported by those who have commented so far. It certainly accommodates extra "kingdoms" without resorting to incertae sedis. Peter coxhead (talk) 11:36, 3 November 2016 (UTC)

Re. "what are the taxobox colours for," it's a good question. To be honest, I don't have an answer. German Wikipedia gets along without them (and the taxonomy there is generally pretty good). Other countries use the colours in a variety of ways, and the results are generally quite inconsistent. French Wikipedia, to take one example, uses colour to differentiate "algae" from "protists", but criteria are unclear, and the application is capricious (the heterotrophic Astasia is considered "algae," for instance; the photosynthetic rhizarian chlorarachniophytes are also considered algae, but Rhizaria itself has the protist colour, etc). Any colour system is inevitably going to divide clades at some place in the tree. Deuterostome (Talk) 13:07, 5 November 2016 (UTC)

Veratrum

Hello --

I don't want an edit war but I challenge your simply deleting an edit I made on Veratrum instead of improving on it. I see how I might further clarify my addition but not if you are just going to again delete it.

Veratrum is in the article described as being a member of the "corn lily" family. My addition "The corn lily family -- distantly related to true lilies -- also includes Beargrass and Deathcamas." is both descriptive and correct. I made this change because the earlier version with its comment about them not resembling lilies is confusing. They do not much look like true lilies, true, and they don't much look like hellebores. But they very much look like other corn lilies, some of which also are toxic.

Before I made this change I added a lengthy explanation in Talk:Veratrum to which you could have (and did not) respond to. If it matters, I have worked in hort and landscaping for over 25 years. I have my own web pages but opt to not publish that on my Wikipedia page -- it would not be that useful in this discussion anyway.

Thanks GeeBee60 (talk) 17:07, 10 November 2016 (UTC)

Sorry for not commenting on the talk page – I've been very busy working in another area of Wikipedia. I still can't see that the addition is helpful in an article about the genus – sure, explain why the genus has its English names, but why mention beargrass and deathcamas? Peter coxhead (talk) 22:35, 10 November 2016 (UTC)

Flower

Why is there a taxobox on the Flower article? --EncycloPetey (talk) 16:18, 18 November 2016 (UTC)

I agree there shouldn't be; I was just fixing the one that was there. I've made major changes to the taxobox code recently (see Template talk:Automatic taxobox/Archive 13#Major rewrite of the colour setting system and Template talk:Taxobox#Update to taxobox colour setting), which have had the side-effect of making strange taxoboxes show up in error-tracking categories. Mostly I've just been rapidly fixing taxoboxes so they don't generate errors, rather than, in most cases, having the time to stop and look more carefully into the issues. Glad you did! Peter coxhead (talk) 16:30, 18 November 2016 (UTC)

ArbCom Elections 2016: Voting now open!

Hello, Peter coxhead. Voting in the 2016 Arbitration Committee elections is open from Monday, 00:00, 21 November through Sunday, 23:59, 4 December to all unblocked users who have registered an account before Wednesday, 00:00, 28 October 2016 and have made at least 150 mainspace edits before Sunday, 00:00, 1 November 2016.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2016 election, please review the candidates' statements and submit your choices on the voting page. MediaWiki message delivery (talk) 22:08, 21 November 2016 (UTC)

World spider catalog

Sorry, i have no idea how to correctly communicate to another user through wiki!

You undid a change i made on a spider page (genus Davus) saying they were 'accepted' in the world spider catalog. That site doesn't not 'accept' or 'deny' anything for taxonomy, it's merely a listing of proposed changes that have been published. Another person/group could equally make another catalog with a different set of proposed taxa listed, differing if they choose to ignore/omit some proposals. Neither of these catalogs would be a definitive 'accepted' version. — Preceding unsigned comment added by Sjl197 (talk • contribs) 01:26, 22 November 2016 (UTC)

@Sjl197: sorry, I didn't notice your post at first because of its placement. There's a lot to learn here! Put comments to users on their talk page, at the bottom.

I agree that choosing the word to use is tricky. However, 'list' clearly isn't right, because the WSC lists all sorts of names: it lists synonyms, for example. The WSC doesn't just list proposals as you say. Its editors make judgements: see e.g. here and the entries for the species involved, e.g. Selenocosmia arndsti. For another example, see Malaridae where there is the comment "Synonymy of the type genus Malkara with Perissopmeros (Murphy & Roberts, 2015: viii) not sufficiently justified and is not accepted here". So the entries in the WSC clearly do involve some degree of 'acceptance'. Peter coxhead (talk) 21:22, 22 November 2016 (UTC)

@Peter coxhead: Absolutely, i'm just learning how to work with Wiki once in a while, so apologies when i get editing stuff wrong! On the issues, i understand your points, and agree their editors at times make judgments, such as those examples. Firstly, though they're not judging per se on the 'taxonomic reality' (i.e. natural groupings), they largely seem to 'judge' on whether a published proposal is sufficiently justified or not for them to warrant updating it in their catalog (or not). Perhaps you're using the term 'accepted' as equivalent to 'preferred current usage'. If so, i think many would agree with you, but i would not. In one of those links, the WSC says "(T to and resurrection of Chilocosmia as opinion, not accepted here)". The critical part of wording I see as vital to consider is the word 'here'. The WSC is what is says it is, a catalog. There have been plenty of other catalogs before them too, i.e. Brignoli, Roewer, Petrunkevitch etc. None of these were authoritative statements on what is 'accepted' per-se in the sense that i worry you might be using, or more importantly perhaps as wiki readers might interpret. Each catalog indeed has/had judgments, each indeed has/had some proposals 'accepted' or not into each catalog. But my point being that none of them are/were in any way definitive (i.e. = 'preferred current usage'). What i was was trying to say before was that other authors or editors can equally make another listing, and it would be no more of ' 'preferred current usage' than WSC is. And this indeed happened with past catalogs which contradict one another. Another way to see that WSC is not definitive I expect could be shown in future by Dr. Gunter Schmidt, if he does 'publish' again on those (heaven forbid, as some of his works are dire), when i expect he'd write the name combination again as Chilocosima arndsti. This would equally ignore/conflict against the 'opinion' of those editors at the WSC! So, in essence, what i'm saying it that - i can 'accept' that technically you can be correct in saying 'accepted by the WSC' (or in exact wording you put with "the World Spider Catalog accepted the following species") but i'd strongly prefer it if you'd avoid the term 'accepted' altogether. So instead to say something like "is LISTED by them" to entirely avoid misunderstanding between 'accepted by them (and perhaps only them)' versus 'widely accepted =preferred current usage'. The essence being that the WSC editors are NOT a taxonomic authority, but editors of a catalog which lists names (inc. synonyms, which are also valid names). It gets to a wider problem that i'm a bit concerned you're trying to make Wiki pages FIT with the WSC as THE definitive source/reference.

@Sjl197: if we wrote "the accepted species are:" or "the species are:" this would be absolutely wrong, for the reasons you give. That's why we write "The World Spider Catalog accepts:" or (for plants) "The World Checklist of Selected Plant Families accepts:". It's their opinion, their judgement. If there are other opinions in reliable sources, other judgements, then they should of course be covered in the article; Wikipedia adopts a neutral point of view.

The places where we just have to pick one point of view are (1) the article title (2) the taxobox. Articles can only have one title; taxoboxes, by their nature, can only show one particular taxonomy. So in those I would virtually always use the WSC – not because it's especially authoritative but because it's virtually complete, and therefore consistent. If we tried to use names/classifications from different sources in article titles and taxoboxes we'd end up with a hopeless muddle. But the text must always show other opinions, so long as these are found in reliable sources of a comparable age (i.e. are not out-of-date).

I can only repeat that "list" is wrong: the WSC doesn't just "list" all names neutrally, regardless of their status. It treats some as its accepted names and others as (junior) synonyms: as soon as you list a name as a synonym you make a judgement as to the 'correct' name. The WSC makes judgements.

The problem with concepts like "widely accepted" or "preferred current usage" is it's difficult or impossible to source them. All we can do is to say what names are accepted by what sources, which is what we should do.

It's also worth pointing out that the purpose of a list of species in a genus article is to provide links to Wikipedia articles; purely by itself the list itself is not encyclopedic. Peter coxhead (talk) 22:44, 22 November 2016 (UTC)

A barnstar for you

		The Template Barnstar
		For all your work improving taxobox templates Plantdrew (talk) 18:25, 19 November 2016 (UTC)

Well deserved! Thanks for all the work, Peter. Deuterostome (Talk) 20:24, 19 November 2016 (UTC)

@Plantdrew and Deuterostome: I was reluctant to accept thanks for this work until I knew that it could actually be finished, i.e. extended to all the automated taxonomy templates. Since the less-used ones, like {{Infraspeciesbox}}, actually do more processing, it wasn't guaranteed that they would work with the changed approach to setting taxobox colour. However, I updated the last one today, and they all seem to work. So thanks for your appreciation! Peter coxhead (talk) 18:13, 23 November 2016 (UTC)

<clap clap> Looks like it was quite a chore. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:16, 28 November 2016 (UTC)

@SMcCandlish: thanks for the appreciation. Yes, it was a chore, although there was a considerable sense of achievement once I'd got it to work. I need to write up what I've learnt about using the template language in a way that minimizes expansion depth in relation to the number of levels of the taxonomic hierarchy that can be traversed. I still don't totally understand how the Wikimedia software counts expansion depth (the explanation given at m:Help:Expansion depth is not exactly well written), but I do now know, partly by understanding and partly by experiment, how to optimize the coding. However, the whole automated taxobox system is very fragile; many pages (like Pteranodon) are at the absolute limit of expansion depth. Peter coxhead (talk) 07:44, 28 November 2016 (UTC)

Are clades ranks or not

Hi Peter, could you please have a look at this discussion. Dwergenpaartje (talk) 17:15, 26 October 2016 (UTC)

Good answer there. I had not seen that discussion, but the question was on my mind for MOS:ORGANISMS purposes. I would still like to advance that to guideline. The only likely hitch is the breed capitalisation thing; I am thinking of going with the "capitalise formal breed names" version and excising the "lower-case it all" version, since the former represents current practice here, for the most part, and MOS:LIFE was carefully written to avoid the issue entirely. Maybe labeling the former a de facto consensus that has seen some controversy, and leave it at that, pending anyone actually launching an RfC about the matter. After the bird-caps fiasco, I've discouraged people from doing this (heading off RfCs about it twice). If one arose now, I would not resist it because enough time has probably passed that the "life forms and capitalisation" issue fatigue has worn off; but I would not relish it. Anyway, that guideline draft is well-researched, and has sat around for years with nearly zero controversy otherwise.

That said, I suppose the nit-pick question is still potentially open: Could a formal clade name (which the examples in that discussion were not) be used as a subgeneric taxon, in Genus_name clade_name order? I would think yes. Would that make the latter a subgeneric rank subject to italicization? I suspect not. I think it would be non-italicized, like a cultivar name and various other non-ranks. Maybe there's an abbreviation that is used in front of it? This isn't a point I've looked into. Clades may be the only missing item in MOS:ORGANISMS WP needs to care about. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:26, 28 November 2016 (UTC)

@SMcCandlish: well, under the nomenclature codes, only the allowed ranks can be used, so a name like Genus_name clade_name would be totally outside their purview. If the PhyloCode ever became widely accepted, which seems no more likely now than it has since it appeared, it italicizes all clade names, and suggests (in Article 21) various ways of distinguishing between species names under the codes and species names under the PhyloCode, e.g. Discodorididae|Diaulula|sandiegensis shows that the species [R]Diaulula sandiegensis belongs to the clades Discodorididae, Diaulula and sandiegensis (the [R] being one way of showing that a rank-based name is being used). So if Genus_name clade_name is meant to show two clades, then it could be written Genus_name|clade_name; however, almost no-one actually does this in reliable sources, so it would be wrong here. If Genus_name clade_name meant to show an informal (i.e. not rank-based) group within a rank-based genus, then it's outside any code, and I would recommend what I wrote before, namely not italicizing the clade name, as we consistently don't for clades at whatever level, but italicizing the genus name, i.e. Genus_name clade_name. I think we agree on this.

There are various problems coming up as clade-based approaches spread, since there is a need to make clear when a name is meant as a formal rank and when it's a clade name, not least because the ending of the name has a meaning in the former case but not in the latter. This recently arose over "Euphyllophyta". If this is a name under the ICN, then it has to be a division/phylum. If you want to lower the position of the group but still use an ICN name, then the ending has to change, e.g. "Euphyllophytina" for a subdivision/subphylum. But many authors seem to be using either name as a clade name, with no rank implication. The most neutral position at present, given that there's no consensus in the literature over whether to use a clade or a rank name, or the rank to be used in latter case, seemed to be to use the informal, "English" name "euphyllophyte".

The nomenclature of higher-level taxa is a complete muddle in reliable sources at present, which makes it hard to know what to do. Recently we've seen a new editor going around trying to impose one particular recent view of the higher levels of plant taxonomy, but this is clearly a POV. Giving every single possible clade a name, as the dinosaur people seem to do, (a) is unhelpful to readers – who can remember what all the clades are? (b) screws up the automated taxobox system by making the hierarchy too deep. Sigh... Peter coxhead (talk) 11:35, 28 November 2016 (UTC)

Big worm-can then. Your "not italicizing the clade name, as we consistently don't for clades at whatever level, but italicizing the genus name" seems reasonable. We could include a footnote that PhyloCode would italicize all clade names, but has not been widely adopted, and WP does not follow it since most RS don't, and the usage will be confusing to readers. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 22:46, 28 November 2016 (UTC)

Miscommunication

I'm not sure why you're throwing your hands up there, and am a bit alarmed that our much-improved mutual communication is taking a backward step. I did think I was addressing your "why isn't this proposal reasonable?" question by pointing out that it serves the interests of opponents of style consolidation and of proponents of unecyclopedic (usually jargonstic) writing, without serving reader interests or those of the broader editorship. And it does seem clear to me that when the sub-topic is style matters that aren't covered in MoS that people over-"enforcing" what is covered in MoS is not the same discussion. I'm not sure where the disjunct is. If you're irritated that I mentioned "wikiprojects of 'experts'", I make that point as the founder or co-founder of many projects (and arguably an expert at some things, but not always the subjects of those projects), and I thought the meaning was clear: wikiprojects are open to anyone, not just actual experts; and actual experts are not under any requirement to join a wikiproject; ergo, "wikiproject" and "experts" are not synonymous. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:02, 12 December 2016 (UTC)

Sarcopterygii in automatic taxoboxes

At Kenichthys (among other Tetrapodomorpha articles) where Sarcopterygii ought to display as a class, it's absent, since it's been skipped in the taxonomy template hierarchy. I understand why that's done, but I don't understand why the result is different than with other paraphyletic groups treated as classes (reptiles). I'm guessing maybe the bird and reptile hierachies maybe fork at some point (perhaps with a parent in the reptile hierarchy that's not included in the bird hierarchy). Is there an easy way to get Sarcopterygii displaying as a class for basal tetrapodomorphs? Plantdrew (talk) 02:03, 5 December 2016 (UTC)

The problem is with knowing what the side-effects would be. As I'm sure you understand, there are two reasons why skip templates have been inserted. The first reason is to shorten taxonomic hierarchies to avoid expansion depth problems. If this is the reason, we can just move the skip a level higher. There are possible longer term solutions, including perhaps recoding parts in Lua. The second reason is to avoid two classes showing up because of very different approaches to classification, as happened with birds. If this is the reason, then it needs quite a bit of investigation. Here the deep underlying reason is that any automated taxobox system has to assume a single agreed classification to work properly, and for vertebrates, there just isn't one. The only real solution I can see would be to have taxonomy templates of the form "Template:Taxonomy/taxon/system", and then different WikiProjects could adopt different systems.

I have limited access/time for the next couple of days, but I'll try to get back to this. Peter coxhead (talk) 08:05, 5 December 2016 (UTC)

@Plantdrew: motivated by the work that Jts1882 has been doing in converting {{Clade}} and {{Cladex}} to Lua, I looked at re-writing some of the core parts of the automated taxobox system in Lua. It took me about 20 minutes to knock up a Lua version of what took me 30-40 hours in the template language – and this was the first time I'd programmed in Lua. As far as I can see, there's no problem in traversing at least 100 levels of the taxonomic hierarchy in Lua. So, my first step is to complete some of this work and include it in the automated taxobox system. Then those skip templates and hard-coded levels needed at present to deal with the expansion depth problem can go, I believe. That should make it much easier to see what skips are actually needed to deal with different classifications. Peter coxhead (talk) 22:48, 7 December 2016 (UTC)

Fantastic news! Plantdrew (talk) 22:54, 7 December 2016 (UTC)

@Plantdrew: I've now deployed the first bit of Lua coding in {{Automatic taxobox}}. It reduces the expansion depth of Pteranodon (the worst case I know of) from the absolute maximum of 40 down to 33. More to come. I hope this won't be a green light for dinosaur editors to add yet more clades! Peter coxhead (talk) 08:53, 8 December 2016 (UTC)

Great. I did ask if there was an "easy way to get Sarcopterygii displaying". Rewriting the taxobox in Lua wasn't exactly what I had in mind as "easy", but if you want to take that on, more power to you. Plantdrew (talk) 17:06, 8 December 2016 (UTC)

@Plantdrew: actually I'm feeling stupid that I didn't do this before (I'm only going to convert those key parts of the automated taxobox system that traverse the taxonomic hierarchy, which is where the problems arise). Not all done yet, so avoiding skip templates would still cause problems. The relevance to your original question can be seen by comparing Template:Taxonomy/Rhipidistia/skip and Template:Taxonomy/Rhipidistia. I think that Sarcopterygii disappears because it was necessary to link to the former rather than the latter to reduce expansion depth. If the expansion depth issue can be fixed, and I now think it can, then we can remove all the skip templates except those necessary to avoid duplicate class ranks, etc.

If a short-term fix is important, it should be ok to go Tetrapodomorpha → Rhipidistia → Sarcopterygii/skip → Vertebrata instead of Tetrapodomorpha → Rhipidistia/skip → Vertebrata, but it's always a matter of trying it and seeing what happens.

The automated taxobox system traverses the taxonomic hierarchy in three distinct places. I've coded one of them in Lua (determining taxobox colour, which is happens first). On to the next two, but it will take several days to code and test. Peter coxhead (talk) 17:41, 8 December 2016 (UTC)

@Plantdrew: ok, to get back to your original question, after a lengthy but I think productive digression.

Now there's no need for skip templates to reduce depth, I took out the skip in the hierarchy for Kenichthys. Looking at Template:Taxonomy/Kenichthys, it seems consistent, so I think it's ok with the skip template removed. However, the manual taxoboxes, like the one at Marsdenichthys appear to treat Tetrapodomorpha as an infraclass, rather than a clade. It's not my area, so I don't know which should be preferred.

Looking around fish taxonomy templates, the only obvious inconsistency I found (which doesn't mean there aren't more) is at Template:Taxonomy/Dipnoi, where there are two subclasses in the hierarchy. Again, I don't know which should be preferred.

It would be nice to have a tool that checked a taxonomic hierarchy for out-of-order Linnaean ranks, although with the ridiculous number of minor ranks used in mammal classification it would be tedious to code. Peter coxhead (talk) 11:43, 12 December 2016 (UTC)

Thanks for fixing the Sarcopterygians. I'm not sure what you mean by "out-of-order Linnaean ranks". Order of parameters doesn't effect the displayed taxobox. It would be nice to have some better tools for checking taxoboxes for consistency though. Plantdrew (talk) 18:12, 12 December 2016 (UTC)

@Plantdrew: all I meant by "out-of-order Linnaean ranks" was that the table shown on the right when looking at "Template:Taxonomy/taxon" shows Linnaean ranks that are not in their correct order, e.g. Order above Class, or another Class above Class. Depending on what is displayed, the taxobox would then also show Linnaean ranks out of their correct order. I hope this is clear now.

{{#invoke:Autotaxobox/sandbox|chkRanks|taxon}} is an experimental tool for checking the ordering of Linnaean ranks in taxonomy templates from taxon upwards.

{{#invoke:Autotaxobox/sandbox|chkRanks|Dipnoi}} as of right now produces Script error: The function "chkRanks" does not exist.

Not a very informative error message, but it's just a draft. One problem is that different sources seem to use prefixes like "mir-" and "parv-" in different ways, so it's not clear what the order should be. Peter coxhead (talk) 18:37, 12 December 2016 (UTC)

Wikipedia:Articles for deletion/Sattva yoga

You nominated the subpages of "User:Taxobot/children" for deletion on Wikipedia:Articles for deletion/Sattva yoga. The appropriate venue seems to be Wikipedia:Miscellany for deletion. Gulumeemee (talk) 08:41, 20 December 2016 (UTC)

@Gulumeemee: whoops, hopefully done correctly now. Peter coxhead (talk) 09:08, 20 December 2016 (UTC)

Pelargonium zonale photo

Doubts about Pelargonia: why do you doubt ? It was written beside her, also can find on same name some similar photos. --PetarM (talk) 12:04, 20 December 2016 (UTC)

@PetarM: I assume we are talking about File:Pelargonium zonale (Geraniaceae).jpg.

Actually, I am certain that this is not a photograph of the wild species. The plant is a cultivar, a member of the Pelargonium Zonal Group. It is correctly in this category on Commons. The wild species has flowers like this image: File:Pelargonium zonale.jpg.

At the place you added the photo, there should be an image of the wild species, not of a cultivar. Peter coxhead (talk) 18:27, 20 December 2016 (UTC)

Viroids

Viroid taxoboxes are displaying the error color. There's a little headache here, because we're mashing together two different classification systems. Baltimore Classification is what we follow for virus groups, but ICTV is the source for lower ranks. ICTV recognizes the viroid families (in their wastebin "families not assigned an order"). I don't know if the Baltimore Classification considers viroids to be viruses or not. Taxonomic list of viruses lists the viroid families under group IV (Positive-sense single-stranded RNA virus) which seems to be an accurate description of the structure of their genetic code. The technical difference seems to be that viroids harness (somehow) the host organsms RNA polymerase II for replication while group IV viruses encode RNA-dependent RNA polymerase themselves. I wonder how much original research has gone into aligning the Baltimore and ICTV systems on Wikipedia?

I'd swear I saw some documentation (or maybe talk page discussion) somewhere that said that including |virus_group= alone, no parameter value needed, was enough to set the virus color, but I'm not finding that documentation now, and a Baltimore Roman numeral value does seem to be required for the color to display. Displaying color without a value might be the best solution; other options would be treating "Viroid" or "Subviral agent" as a Virus Group (probably WP:OR) or adding "unassigned" as a value that allows the virus color to display (or just go with |color_as=. Plantdrew (talk) 04:00, 20 December 2016 (UTC)

Having stopped |color= having any effect in {{Automatic taxobox}} and {{Taxobox}} yesterday evening, I expected that overnight the error-tracking categories would be quite full, so I was pleased to see the few articles there!

I think that using the same colour in the taxobox for viroids as for viruses is the best solution; there aren't enough articles to make it worth thinking about using a different colour. So I've added "viroid" and "viroids" to {{Taxobox colour}}. The taxobox doesn't need to say that viroids are viruses (which might well be OR); we just use the same colour for both on the grounds of similarity. Peter coxhead (talk) 06:47, 20 December 2016 (UTC)

@Plantdrew: in the last hour or so, some virus articles turned up in Category:Taxoboxes with the error color, most with |color=violet. I've fixed them all. Some don't have a virus group specified, so I used |color_as=Virus; others did, but not with a recognized value, so I corrected it.

I'm not sure whether just putting |virus_group= without a value did previously set the taxobox colour; it certainly doesn't since my recent edits. It's possible to make this happen (it works with {{Taxobox/sandbox}}), but it violates the usual expectation that omitting a parameter and having it present but with no value should have the same effect, so I'm not keen to make this live, unless you think it would be a really good idea.

It does seem so far that ignoring |color= only causes relatively few and fixable problems, but I know from past experience that template-determined categorization can take a long time to take effect, so the situation may change. Peter coxhead (talk) 11:09, 20 December 2016 (UTC)

Nah, don't bother making blank |virus_group= set color. Most of the missing colors that are turning up are due to other problems in the taxobox that should be fixed anyway, so even if we do get a flood of missing colors, I think it's good that the articles are getting flagged as having a problem. Plantdrew (talk) 17:50, 20 December 2016 (UTC)

Ok. Earlier today (my morning) most of those I found had other problems, too. I guess that editors who set |color=, especially to unexpected colours like the "violet" and "darkgreen" ones I found, didn't really understand taxoboxes and made other errors. I see you've fixed a lot, including fuller fixes to some articles for which I'd just sorted out the colour. Peter coxhead (talk) 18:28, 20 December 2016 (UTC)

Extended confirmed protection policy RfC

You are receiving this notification because you participated in a past RfC related to the use of extended confirmed protection levels. There is currently a discussion ongoing about two specific use cases of extended confirmed protection. You are invited to participate. ~ Rob₁₃^Talk (sent by MediaWiki message delivery (talk) 16:31, 22 December 2016 (UTC))

Donald Pigott

Seasons greetings. I noticed you deleted C.D.Pigott, I'm doing a biography on him (as part of a larger project on Cambridge botanists). This is a recurrent problem, alternative authority abbreviations. In the Tilia literature C.D.Pigott appears after taxa names. Do you have a solution?! Michael Goodyear (talk) 03:22, 24 December 2016 (UTC)

@Michael Goodyear: my real concern is to ensure that all entries in the lists are sourced, using a source that clearly identifies the botanist, which must include date(s). Entries in IPNI are sourced by default; all others need an explicit reference. So if you have a source that clearly identifies "C.D.Piggott" as IPNI's "Pigott – Christopher Donald Pigott 1928-", by all means restore "C.D.Pigott" with this reference. However, it does seem to me that the real point of the lists of botanists by author abbreviation is to decode ones like "Art.Mey.", and where a full name (including full initials + surname) is used, I think that all readers need is a wikilink.

Season's greetings to you too! Peter coxhead (talk) 08:35, 24 December 2016 (UTC)

In this case the source is Tropicos, so I should probably restore it. It may make its way from there to IPNI given that he is a living botanist.--Michael Goodyear (talk) 16:19, 24 December 2016 (UTC)

@Michael Goodyear: Tropicos seems to use "Pigott" when I looked; certainly it does here. Where does it use his full name? Please add a source for "C.D.Pigott", otherwise it looks as though it's in IPNI, which it isn't. Peter coxhead (talk) 17:35, 24 December 2016 (UTC)

Actually I think you are right - if you search Tropicos for Pigott you get three entries

Pigott, C.D.
Pigott, Christopher Donald
Pigott, Julian Patrick

which I inadvertently read as an approved name since I had seen it written that way, but it is the third column that matters not the first that only gives Pigott. But I had seen CDPigott in numerous places such as here but if you go back to Pigott's original paper describing the taxon, he just uses Pigott. I will delete it - thanks! --Michael Goodyear (talk) 22:43, 24 December 2016 (UTC)

Donald Pigott now published --Michael Goodyear (talk) 23:21, 24 December 2016 (UTC)

Move assistance

I just came across a homonym situation with some snakes and was hoping you could help. Pseudoeryx Jan, 1862 is a redirect in the synonymy of Charina. Pseudoeryx (genus) Fitzinger, 1826 is newly created. (genus) isn't a sensible dab term in this case, and I think the senior homonym just needs to usurp the title completely from the junior homonym. I'm not quite sure if it's kosher to use round robin moves to disappear the (genus) title altogether. Incoming links to Pseudoeryx all intend Fitzinger's genus. Plantdrew (talk) 22:24, 28 December 2016 (UTC)

Done Just swapping them seems fine to me. If the synonym Pseudoeryx is used significantly, there could be a hatnote at Pseudoeryx pointing to Charina, but I leave that to you. Peter coxhead (talk) 09:22, 29 December 2016 (UTC)

Cichorieae subtribes

Seasonal Greetings from me as well. I'd like some guidance on a couple of issues which I will split up over two headings.

The first issue has to do with some work I've done on Cichorieae, among which devising phylogenetic trees. I made one to the level of subtribes. I made three further ones that elaborate to the level of genera for clusters of subtribes. Could you have a look at it. Do you think articles for each of the subtribes need to be created?

Ok, will do, but I won't have much time for the next few days.

Personally, I'm biassed against articles on ranks like subtribes, but on the other hand Asteraceae is such a large family that dividing up is necessary. Peter coxhead (talk) 09:31, 29 December 2016 (UTC)

Great, I'm not in a hurry, so please take your time. Dwergenpaartje (talk) 17:37, 29 December 2016 (UTC)

I'm also working on Gymnarrhena micrantha (henceforth in my sandbox), the only species of the subfamily Gymnarrhenoideae (Asteraceae). Should a redirect for the subfamily be created? And should the subfamily be included in the text of the article, and what about in the taxobox? Many thanks in advance, kind regards, Dwergenpaartje (talk) 14:43, 28 December 2016 (UTC)

WP:FAUNA is the guide here. The article should be at the genus name, and should cover all monotypic taxa above that rank and the species below it, with redirects from all the other ranks (the general principle is to be free with taxonomic redirects). Personally I wouldn't put a monotypic subfamily in the taxobox; what does it tell readers? Peter coxhead (talk) 09:31, 29 December 2016 (UTC)

Clear enough, I'll proceed along those lines, thanks. Dwergenpaartje (talk) 17:37, 29 December 2016 (UTC)

Amphicarpy

Hello again. I referenced and extended the article on Amphicarpy. Now, I came across an article that elaborates amphicarpy, basicarpy and geocarpy, and lists a large number of examples. Do you think it would desirable to create a list of amphicarpic, basicarpic and geocarpic species, and if so, what do you think should be the title?

Another issue is that there is also a Wiktionary lemma on the same topic, which has a rather different, although consistent circumscription. Should Wiktionary and Wikipedia articles be more identical? What can be done in this case?

Thanks for your council again! Dwergenpaartje (talk) 14:43, 28 December 2016 (UTC)

@Dwergenpaartje: you need a real botanist for that question, I'll ping one – @Sminthopsis84: one for you! Peter coxhead (talk) 15:09, 28 December 2016 (UTC)

There are some points that need fixing on those pages before a list is attempted. I'll make some changes at wiktionary. Amphicarpy is used by some authors to mean simply having more than one type of fruit, but others have lots of separate terms. Various grasses of genera such as Stipa are memorable if you wear socks; they have fruit that drill their way into soil or flesh, and they don't fit the current definition at Geocarpy because the fruit have detached from the plant when they take aim at your fibular artery. Hesperostipa spartea is one where geocarpy is already mentioned.

I think that a list of plants with amphicarpous fruits could potentially be very long. It is very difficult to describe in sufficient detail how different people have created their own sets of terms, as this guy has. Sminthopsis84 (talk) 20:36, 28 December 2016 (UTC)

I'll remember that information next time I'm removing thousands of seedlings of Stipa tenuissima from between cracks in paving - they probably drilled their way down there.... (strange we don't have an article on S. tenuissima - unless it's a synonym?) PaleCloudedWhite (talk) 19:06, 28 December 2016 (UTC)

I guess you'd use very tiny forceps for that. It looks as if the US states of New Mexico and Texas could use your help. The Plant List calls S. tenuissima a synonym of Nassella tenuissima, but we don't have a page for that either. Sminthopsis84 (talk) 20:36, 28 December 2016 (UTC)

GrassBase concurs with TPL (which is not surprising, since TPL gets its record from Kew); Tropicos here prefers Stipa to Nassella. Peter coxhead (talk) 21:26, 28 December 2016 (UTC)

That's not how I'd read Tropicos; 10 sources go with Nasella, all but one of them published since 1997. Another 10 sources go with Stipa, but only one was published after 1994. More recent sources overwhelming go with Nassella. Interpretating Tropicos is a 4 step process.

1: check for a * vs a !; * names are illegitimate/rejected.

2: Count citations in the Accepted names tab (accepted as something else) and the References tab (accepted as the name currently being viewed).

3: If the results in step 2 aren't conclusive, look at publication dates of the works cited and go with more recent consensus.

4: Check for taxonomic authoritativeness. A "Systematic revision of the genus Fooia" published 5 years ago probably trumps a "Checklist of the vascular flora of East Podunk County Park" published 2 years ago. Plantdrew (talk) 22:11, 28 December 2016 (UTC)

@Plantdrew: yes, I'd looked at Tropicos too hastily (Christmas holiday alcohol?). Peter coxhead (talk) 09:14, 29 December 2016 (UTC)

I've provided a source for the statement that amphicarpy dominantly occurs in annuals. If a list would be too long, a category would be a better suggestion? Dwergenpaartje (talk) 22:09, 28 December 2016 (UTC)

A list would get very long if people add plants that simply have fruit of more than one type (e.g., with large wings or with small wings, fruit of six different weight categories, etc.). I think that is likely to happen at some point, and wikipedia isn't in the business of deciding which of the definitions of amphicarpy to accept. As for a category instead of a list, I wouldn't advise that because there is no way to monitor the contents of a category, vandals can come in and strip it, and there is no systematic way to recover. Sminthopsis84 (talk) 13:13, 29 December 2016 (UTC)

All I will say about this subject, as an amateur botanist, is that when working on some of the fruit-related articles, it became clear to me that there are major differences in the terminology used for fruit by different reliable sources. We badly need a balanced article covering botanical fruit classification. Peter coxhead (talk) 21:42, 29 December 2016 (UTC)

There is a baby page at Nassella tenuissima now, ready for additions. Sminthopsis84 (talk) 13:43, 29 December 2016 (UTC)

Wikipedia:Miscellany for deletion/Taxobot children

After going through your contributions I was able to get to Wikipedia:Miscellany for deletion/Taxobot children. However, I can't see which of the pages you put the MfD on. Thanks. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 23:00, 29 December 2016 (UTC)

@CambridgeBayWeather: all of the very large number of pages listed at [1] were created by a bot no longer running and are not used or needed now. There are far too many to tag individually, or indeed delete individually. I assume there's some way of deleting all subpages of Taxobot/children/. The pages aren't actively harmful, I think; it would just be tidier to get rid of them all. Peter coxhead (talk) 23:06, 29 December 2016 (UTC)

I can delete them within a couple of minutes but can you assure me that I won't brake anything. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 23:30, 29 December 2016 (UTC)

Does that include everything up to https://en.wikipedia.org/w/index.php?title=Special:PrefixIndex&from=Taxobot%2Fchildren%2FTrigonidiinae&prefix=Taxobot%2Fchildren&namespace=2 ? CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 23:39, 29 December 2016 (UTC)

I can only say that knowing how these pages got created and how they were intended to be used makes it clear to me that they can safely be deleted. The pages fall into two groups: a large group with names of the form "Taxobot/children/name-of-taxon", none of which are linked to and all of which are potentially out-of-date anyway and would be re-created should Taxobot ever be allowed to run again; and a few oddities, like User:Taxobot/children/template and User:Taxobot/children/preload, which are actually templates although not in Template namespace, that I have checked individually and have no transclusions.

So, yes, I am confident that they can all be deleted, from User:Taxobot/children/ to User:Taxobot/children/template. Peter coxhead (talk) 08:57, 30 December 2016 (UTC)

All 2,945 deleted. Glad that WP:TWINKLE allows for mass deletes. Got the lot in three minutes. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 00:24, 31 December 2016 (UTC)

@CambridgeBayWeather: yes, I saw. Thanks! It's good to be tidy for the New Year – Happy New Year to you! Peter coxhead (talk) 08:45, 1 January 2017 (UTC)

Testcases page in mainspace

Why did you move Template:Autotaxobox/testcases to mainspace at Autotaxobox/testcases with no redirect when subpages are discouraged in mainspace? The best location is Module:Autotaxobox/testcases, which you have created with a link to the incorrect mainspace page. Merry Christmas and Happy New Year, GeoffreyT2000 (talk, contribs) 00:49, 30 December 2016 (UTC)

GeoffreyT2000 Because I don't think he can. I just tried and got "Non-Module pages cannot be moved to the Module namespace (except for /doc pages), and Module pages (except for /doc pages) cannot be moved out of the Module namespace." If admins can't move it then I'm not sure who can. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 01:02, 30 December 2016 (UTC)

@GeoffreyT2000: it's exactly as CambridgeBayWeather says. I discovered that any page in the Module namespace is assumed to be Lua. Since Module:Autotaxobox is only designed to be used by being called from existing templates that make the automated taxobox system work, the best way to test it is not from Lua code but from those templates.

"Template:Autotaxobox/testcases" isn't right because it assumes there is a "Template:Autotaxobox" page to which it links, and there isn't.
I agree that mainspace "Autotaxobox/testcases" isn't right either.
"Module talk:Autotaxobox/testcases" would appear to be possible, although it seems odd to me to put testcases in a talk namespace. It also puts up a message saying "The purpose of this page is to run the testcases stored at Module:Autotaxobox/testcases. Any discussion about them should be posted at Module talk:Autotaxobox, not here." But there is no "Module:Autotaxobox/testcases".
Another alternative is to write Lua code that calls templates that call the functions in Module:Autotaxobox, but (a) this seems pointless (b) the Lua test code then needs updating if the calling templates change and if this is forgotten the tests will be wrong (c) this introduces another layer in which errors could occur which is undesirable.

So I don't know what to do. There seems to be nowhere to put testcases written in the template language. Peter coxhead (talk) 08:37, 30 December 2016 (UTC)

Addendum: testing shows that it would be possible to put the testcases at a title like "Module talk:Autotaxobox/test cases"; it's the exact string "testcases" that triggers the undesirable edit notice. Peter coxhead (talk) 08:41, 30 December 2016 (UTC)

User:Edgars2007 moved the page to Module talk:Autotaxobox/testcases, which I don't like because of the incorrect edit notice, so I moved it again to Module talk:Autotaxobox/test cases, which avoids this edit notice, but then implies that there is a page Module:Autotaxobox/test cases. Sigh...

There seems nowhere to put test cases for a Lua module when they are written in the template language, yet when Lua is used solely to support other templates making up a system, the only reliable tests are from within those modules. As a software engineer, it seems to me quite wrong to write tests in Lua that simulate calls from a template, as per Module:String/testcases, which is what it seems you are supposed to do. These aren't direct tests, and make it difficult to construct a table showing differences between the deployed and sandbox versions, which is vital in testing possible changes. Peter coxhead (talk) 09:23, 30 December 2016 (UTC)

I agree - there's no ideal place to put these test cases. Perhaps in the future we could add another namespace to Mediawiki for running module tests, but for now we have to work with what we have. I think that the least-worst solution at the moment would be to put the test cases at Template:Autotaxobox/testcases and leave a short explanation at Template:Autotaxobox linking to the module page. The conceptual link between templates and modules is well-established enough in people's minds here that that would not seem too unnatural. The next-least-worst option would be to put the page in the Module talk namespace as you have done. There are some existing examples of this, although pages like Module talk:Foo/testcases are generally reserved for displaying the results of a test module at Module:Foo/testcases (hence the annoying edit notice). I believe it is possible to override the edit notice, so using the standard title of Module talk:Autotaxobox/testcases with a blank edit notice may be slightly better than the current non-standard title of Module talk:Autotaxobox/test cases. — Mr. Stradivarius ^{♪ talk ♪} 10:36, 30 December 2016 (UTC)

@Mr. Stradivarius, Edgars2007, GeoffreyT2000, and CambridgeBayWeather: thanks particularly to Mr. Stradivarius, the position now is "least worst", I think, but still not ideal – there needs to be a proper location for template language testcases for Lua modules. Where should this be taken up? Peter coxhead (talk) 08:50, 1 January 2017 (UTC)

Error on Oldhamia and some other like pages

{{children_rank|{{taxonomy/{{Taxobox/taxon|Oldhamia| }}|rank}} }}

{{Taxobox/taxon|Oldhamia| }}

{{taxonomy/Oldhamia|rank}}

{{children_rank|ichnogenus }}

I can't figure this out. When I break out the component templates it works, but the package at the top errors. I can't find anything that's changed recently, and this is a new error on a page that presumably worked before. I'm guessing that it's related somehow to changes you've been making. – wbm1058 (talk) 05:48, 6 January 2017 (UTC)

@Wbm1058: firstly, apologies; this will indeed have been caused by some of the changes I have made. I have to confess that I have been concentrating on the 'main' system and have been aware that I haven't been checking the much less used 'ichno' and 'oo' taxoboxes as thoroughly as I should have.

The work-around is to explicitly supply |subdivision_ranks=, in the case of Oldhamia |subdivision_ranks=Ichnospecies. I'll try to fix the underlying problem as soon as I can. Peter coxhead (talk) 09:00, 6 January 2017 (UTC)

Fixed now, I think. I'd forgotten to apply a change made to {{Automatic taxobox}} to {{Ichnobox/short}}. However, I consider it good practice to explicitly supply |subdivision_ranks=; I've found quite a few taxoboxes where the subdivisions in the taxoboxes weren't actually at the automatically determined rank, especially at higher levels, e.g. for an order the predicted subdivision ranks are families, but this is rare now – usually there are suborders, etc. or more likely clades. Peter coxhead (talk) 09:15, 6 January 2017 (UTC)

As I see from your user page that you're a programmer, I thought I should offer an explanation. Ignore if you're not interested. The automated taxobox system is littered with templates and code left over from its development; usually a better version has been implemented, but a few calls to the original version got missed. I've been trying to remove these because they make the system hard to maintain. One example is uses like {{Taxonomy/Oldhamia|rank}} instead of the more efficient {{Taxonomy/Oldhamia|machine code=rank}}. I thought I'd found all calls of the first kind, but wasn't sure, so I made such calls put the caller in a tracking category. In the few ichnobox cases you saw, the non-visible [[:Category:...]] caused {{children_rank}} to fail. Peter coxhead (talk) 10:04, 6 January 2017 (UTC)

Happy to see that it was an easy fix for you. The taxobox templates are still difficult for me to follow. I don't have any background in biology or the classification systems. Regards, wbm1058 (talk) 21:58, 6 January 2017 (UTC)

Template protections

Hi Peter, officially you should have gone to WP:RFPP but in the interests of reducing bureaucracy I have actioned those requests for you. In future it would be easier if you could make the request in one place rather than creating a dozen separate requests. Best regards — Martin (MSGJ · talk) 14:57, 9 January 2017 (UTC)

@MSGJ: thanks very much! The reason for multiple requests was partly that I didn't realize that so many of the "Don't edit this line XXX" variants were fully protected; the first few I dealt with were only template editor protected. I'll do things properly in future :-). Peter coxhead (talk) 15:20, 9 January 2017 (UTC)

Metadata

Can I ask why you chose to remove metadata from the article on moss after I added it? Human-readable reference names are beneficial, and would only be unnecessary if Wikipedia was write-once-modify-never. You may not think it's necessary to add such names yourself, but once they've been added, I see no reason to remove them — or, for that matter, to describe their addition as 'pointless'.

I look forward to your explanation. DS (talk) 22:45, 17 January 2017 (UTC)

@DragonflySixtyseven: Edits made to the wikitext that don't affect what readers see may be acceptable if made in passing as part of useful edits that do affect what readers see. Otherwise most of them just put a load on the server unnecessarily. Why do you think that your choice of ref names is better than the original editor's? I have my preferences (and like you I would never choose the ref names you changed). But we shouldn't edit articles just to suit our preferences as editors. Chopping and changing things like ref names is pointless and time-wasting. It's just the same as editors who go around changing "[[Xs|X]]" to "[[X]]s", or "<ref name=X>" to "<ref name="X">" (the ref tag is not XML, but a special wikimedia feature), without making any other useful changes to the article.

Usually I just sigh to myself when I see this kind of edit; I don't remember now, but I had probably seen too many that day when I undid your changes. Add them back if you want, but I stand by my view that such edits are generally pointless and time-wasting. Peter coxhead (talk) 09:32, 18 January 2017 (UTC)

The point is that :0, ;1, :2, :3, etc are not anyone's choice of ref names. They're what Visual Editor inserts by default, unless you know to tell it to include ref names. And having two clashing systems of numbering can lead to confusion (reference ":7" can be footnote 22? reference ":8" can be footnote 35?), especially when people copy references wholesale from one article to another. It's like having illustrations whose filenames are 001.jpg, 002.jpg, 003.jpg, and 345678909876567gyuyguy65r76t8yujifacebook.cdn.4567890.jpg. When filenames have actual semantic value, that greatly facilitates page maintenance — and when they don't, that greatly hinders it. It's the same for ref names. DS (talk) 15:27, 18 January 2017 (UTC)

I'm happy to let you have the last word. Peter coxhead (talk) 15:32, 18 January 2017 (UTC)